Server configuration including stream preview

ABSTRACT

A method includes receiving first input from a computing device, the first input corresponding to selection of a first media player associated with a first output stream format. In response to the first input, a first stream preview is sent to the computing device in accordance with the first output stream format. The method includes receiving second input from the computing device, where the second input corresponds to selection of a second media player associated with a second output stream format. In response to the second input, a second stream preview is sent to the computing device in accordance with the second output stream format.

CROSS-REFERENCE TO RELATED APPLICATIONS

The present application is a continuation of and claims priority to U.S.Non-Provisional patent application Ser. No. 14/619,936 filed on Feb. 11,2015 and issued on May 10, 2016 as U.S. Pat. No. 9,338,203, which claimspriority to U.S. Provisional Patent Application No. 61/938,633 filed onFeb. 11, 2014, the contents of which are incorporated by reference intheir entirety.

BACKGROUND

The popularity of the Internet, coupled with the increasing capabilitiesof personal/mobile electronic devices, has provided consumers with theability to enjoy multimedia content almost anytime and anywhere. Forexample, live (e.g., sports events) and video on demand (VOD) content(e.g., television shows and movies) can be streamed via the Internet topersonal electronic devices (e.g., computers, mobile phones, andInternet-enabled televisions).

In a client-server system, a server may provide a multimedia stream toeach client device that requests the stream. Due to the variety ofclient devices available to consumers, different client devices mayrequest versions of a stream that differ with respect to resolution,streaming protocol, encoding format, etc. Due to the large number ofpossible stream configurations, configuring and testing the server maybe a cumbersome and time-consuming process.

SUMMARY

The present disclosure is directed to a graphical user interface (GUI)that is generated by a media server to enable a user or an administratorto configure the media server. The GUI may receive input that causes themedia server to receive or to simulate receipt of a media stream (e.g.,a live or on demand stream of audio data, video data, or both). The GUImay also receive input to configure a transcoding and/or transmuxingmodule of the media server. The GUI may further be configured todynamically instantiate test media players to play different streamsoutput by the media server. Thus, the GUI may enable a user or anadministrator to test the media server's ability to generate multipleoutput versions (e.g., adaptive bitrate (ABR) renditions) of an inputstream, where the output versions differ with respect to one or more ofstreaming protocol, bitrate, resolution, audio encoding, video encoding,etc. The described GUI may thus provide a one-stop stream testingsolution that can be used by a user or administrator prior to puttingthe media server in a production or client facing environment.Advantageously, the described GUI-based stream testing mechanism doesnot require a user or administrator of the server to test differenttypes of streams by connecting to the media server using different typesof devices (e.g., different mobile phones, tablet computers, laptopcomputers, set-top boxes, etc.).

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a diagram of a particular embodiment of a system that isoperable to support configuration of a media server via a GUI thatincludes stream previews;

FIG. 2 illustrates a first particular embodiment of the GUI of FIG. 1;

FIG. 3 illustrates a second particular embodiment of the GUI of FIG. 1;

FIG. 4 illustrates a third particular embodiment of the GUI of FIG. 1;

FIG. 5 illustrates a fourth particular embodiment of the GUI of FIG. 1;

FIG. 6 illustrates a fifth particular embodiment of the GUI of FIG. 1;

FIG. 7 illustrates a sixth particular embodiment of the GUI of FIG. 1;

FIG. 8 illustrates a sixth particular embodiment of the GUI of FIG. 1;and

FIG. 9 is a flowchart of a particular embodiment of a method ofoperation at the media server of FIG. 1.

DETAILED DESCRIPTION

FIG. 1 illustrates a particular embodiment of a system 100 that isoperable to support configuration of a media server 150 via a graphicaluser interface (GUI) 115 that includes stream previews.

The media server 150 may include one or more processors 151 and variouscomponents that are executable by the processor(s) 151. The media server150 may correspond to or include software application(s) that performmedia serving or processing, hardware systems (e.g., servers) thatsupport or perform media serving and processing, or any combinationthereof. Thus, various operations described with reference to the mediaserver 150, or components thereof, may be implemented using hardware,software (e.g., instructions executable by the processor(s) 151), or anycombination thereof.

The media server 150 may include one or more network interfaces 152. Forexample, the network interface(s) 152 may include input interface(s) andoutput interface(s) that are configured to receive data and to senddata, respectively. In a particular embodiment, the network interface(s)152 may be wired and/or wireless interfaces that enable the media server150 to communicate data via a network, such as the Internet. Forexample, the network interface(s) 152 may include an Ethernet interface,a wireless interface compatible with an IEEE 802.11 protocol, or otherwired or wireless interfaces.

The media server 150 may include various components configured toperform stream processing functions. For example, the media server 150may include one or more video processing components, such as theencoders 153, the decoders 154, and transcoders 155, each of which maybe implemented using hardware, software (e.g., instructions executableby the processor(s) 151), or both. The decoder(s) 154 may decode datareceived by the media server 150. For example, the decoder(s) 154 maydecode a received media stream 104 (e.g., a live or video on demand(VOD) audio-only, video-only, or audio-video stream). The encoder(s) 153may encode data that is to be transmitted by the media server 150. Thetranscoder(s) 155 may be configured to perform bitrate conversion, CODECconversion, frame size conversion, etc. In a particular embodiment, atranscoding operation performed by the transcoder(s) 155 may trigger adecoding operation by the decoder(s) 154 and/or a re-encoding operationby the encoder(s) 153. In a particular embodiment, parameters used bythe transcoder(s) 155 are stored in one or more transcoding templates156 at the media server 150. Alternately, or in addition,encoding/decoding/transcoding parameters, as well as other configurationoptions for the media server 150, may be received via a serverconfiguration GUI, as further described herein.

The encoder(s) 153, decoder(s) 154, and transcoder(s) 155 may thusenable the media server 150 to process data in accordance with multiplecoding technologies and protocols. To illustrate, the media server 150may convert a media stream (e.g., audio and/or video data) from oneformat or transmission protocol to multiple other formats ortransmission protocols. For example, video streams received andtransmitted by the media server 150 may be associated with the sameencoding format and transmission protocol or may be associated withdifferent encoding formats and transmission protocols. In a particularembodiment, the media server 150 may generate video streams byperforming video decoding, encoding, transcoding, and/or transmuxingoperations (e.g., to modify a video encoding format, an audio encodingformat, a bitrate, an aspect ratio, packaging, etc.). In a transmuxingoperation, encoded audio and video may be repackaged without modifyingthe encoded audio and video.

For example, the media server 150 may support video encoding typesincluding, but not limited to, H.264, On2 VP6, Sorenson Spark, Screenvideo, Screen video 2, motion picture experts group (MPEG) 2 (MPEG-2),and MPEG-4 Part 2. The media server 150 may support audio encoding typesincluding, but not limited to, advanced audio coding (AAC), AAC lowcomplexity (AAC LC), AAC high efficiency (HE-AAC), G.711, MPEG AudioLayer 3 (MP3), Speex, Nellymoser Asao, and AC-3.

Further, the media server 150 may support communication (e.g., adaptivestreaming and non-adaptive streaming) protocols including, but notlimited to, hypertext transfer protocol (HTTP) live streaming (HLS),HTTP dynamic streaming (HDS), smooth streaming, and MPEG dynamicadaptive streaming over HTTP (MPEG-DASH) (also known as internationalorganization for standardization (ISO)/international electrotechnicalcommission (IEC) 23009-1). The media server 150 may also support realtime messaging protocol (RTMP) (and variants thereof), real-timestreaming protocol (RTSP), real-time transport protocol (RTP), andMPEG-2 transport stream (MPEG-TS). Additional audio formats, videoformats, coder/decoders (CODECs), and/or protocols may also besupported.

In a particular embodiment, the media server 150 includes one or moredata storage devices 159 (e.g., random access memory (RAM), disk-basedstorage, solid-state non-volatile memory, etc.). The data storagedevice(s) 159 may store stream data (e.g., frames of a live or VODstream), files, closed caption data, images (e.g., to be overlaid on topof a video stream), etc.

The media server 150 may be configured to send and receive data fromvarious other devices. For example, the media server 150 may communicatewith one or more playback devices 170 (e.g., devices that are configuredto stream video content) and one or more other servers 180. Examples ofplayback devices include a smartphone, a tablet computer, a laptopcomputer, a desktop computer, a set-top box, a television, a portablemedia player, a game console, etc. In the embodiment of FIG. 1, theplayback devices 170 include a desktop/laptop computing device 171, atelevision (TV)/set-top box 172, a smartphone 173, and a tablet computer174. Examples of servers include a media server, a stream relay server,a server of a content distribution network (CDN), such as an edgeserver, etc. In the embodiment of FIG. 1, the other servers 180 includea media server/stream relay server 181 and a server of a CDN 182.

In a particular embodiment, the media server 150 supports adaptivebitrate (ABR) streaming. For example, the media server 150 may performone or more stream processing operations on the media stream 104 togenerate a plurality of ABR renditions 165, 166. In a particularembodiment, the media server 150 generates an adaptive streamingmanifest 163 that includes information describing each of the ABRrenditions 165, 166 that are available for adaptive streaming. Toinitiate an adaptive streaming session, a destination device, e.g., thecomputing device 171, may request the manifest 163. Upon receiving themanifest 163, the computing device 171 may determine which of theavailable renditions should be requested from the media server 150. Forexample, the computing device 171 may make such a determination based onbuffering/processing capability at the computing device 171 and/ornetwork conditions (e.g., bandwidth) being experienced by the computingdevice 171.

Upon determining which rendition should be requested, the computingdevice 171 may transmit a request 164 to the media server 150. Therequest 164 may specify a particular portion (e.g., portion “X”) of therequested rendition. The particular portion may be specified usingstart/end frame numbers, start/end times, a portion number/identifier,etc. Depending on the adaptive streaming protocol in use, the requestedportion may correspond to a “chunk” of a rendition and/or a group ofpictures (GOP). A “chunk” may refer to a fixed (e.g., ten seconds) orvariable length duration of a stream rendition. A group of pictures mayrefer to a collection of video frames that includes one or moreintra-coded frames (I-frames) and one or more additional frames thatinclude difference information relative to the one or more I-frames(e.g., P-frame and/or B-frames). If there are no problems with receiptand playback of the requested portion, the computing device 171 mayrequest a subsequent portion (e.g., portion “X+1”) of the samerendition. However, if playback and/or network conditions become worse,the computing device 171 may switch to a lower bitrate rendition byrequesting subsequent portions of the lower bitrate rendition.Conversely, if playback and/or network conditions improve, the computingdevice 171 may switch to a higher bitrate rendition. The media server150 may generate key frame aligned portions for the adaptive streamingrenditions, so that switching to a lower bitrate or higher bitraterendition appears “seamless” (e.g., does not result in noticeable visualglitches or dropped frames).

To aid in configuration of the media server 150, the media server 150may include a GUI server 157. The GUI server 157 may be configured togenerate a server configuration GUI 115. In a particular embodiment, theGUI server 157 is a web server and the GUI 115 is accessible at aparticular uniform resource locator (URL) via a web browser (e.g.,http://www.mymediaserver.com:8088). The GUI 115 may be embodied as oneor web pages in accordance with hypertext markup language 5 (HTML5) andcascading style sheets 3 (CSS3). As a user or administrator interactswith the GUI 115, additional web pages may be presented. Each additionalweb page can be considered part of the GUI 115 or a separate GUI. TheGUI 115 may be displayed by a display device 116, and may present (e.g.,to a user or an administrator) various configuration options for themedia server 150. In a particular embodiment, the display device 116 iscoupled to the media server 150. Alternately, the display device 116 maybe part of or coupled to a computing device 119 that is remote from themedia server 150. To illustrate, the display device 116 may be part ofor coupled to a desktop computer, a laptop computer, a server computer,a mobile device (e.g., a mobile phone, a smartphone, a tablet computer,etc.), or any combination thereof, that is configured to communicatewith the media server 150 via a network (e.g., the Internet).

A user or administrator may interact with the GUI 115 via an inputdevice 117 (e.g., a keyboard, a mouse, a touchscreen, etc.) to provideuser input 118. The input device 117 may be coupled to the media server150, or may be part of or coupled to a computing device 119 that isremote to the media server 150. The user input 118 may be responsive tothe GUI 115 (e.g., may include selections or input values correspondingto server configuration options presented by the GUI 115).

During operation, a user/administrator may use the GUI 115 to set up VODstreaming and/or live streaming. For example, in VOD streaming, themedia stream 104 may correspond to pre-recorded content received from aremote device. Alternately, the pre-recorded content may be retrievedfrom the data storage device(s) 159 at the media server 150. As anotherexample, in live streaming, the media stream 104 may correspond tocontent being captured via a camera and/or microphone. The live or VODstream may be received from the computing device 119 (e.g., the deviceto which the GUI 115 is sent and from which the user input 118 isreceived). For example, in a single-computing-device device testenvironment, the single computing device may capture a live media streamor generate a VOD media stream from a stored file, include the displaydevice 116, include the input device 117, and include the media server150 that generates multiple output streams corresponding to differentoutput formats.

In a particular embodiment, setting up VOD or live streaming may includeproviding the user input 118 indicating stream playback type(s), such asone or more of HDS, RTMP, HLS, smooth streaming, MPEG-DASH, RTSP, RTP,or mobile. Setting up VOD or live streaming may also include setting upstream playback and/or publishing security, such as whether to restrictstream viewers to particular IP addresses, whether to restrict streamembedding to particular domains, whether to require a password forpublishing, etc.

After setting up live or VOD streaming, a user or administrator may usethe GUI 115 to test output streams (e.g., the ABR renditions 165, 166)corresponding to the selected playback types. For example, the user oradministrator may select a “Test Players” button on the GUI 115 todynamically instantiate one or more test players (e.g., media players)to connect to (or to simulate connecting to) the media server 150 andplay back particular output streams. Each test player may includevarious functions and features, such as the ability to rewind thecorresponding output stream (e.g., by 30 seconds), play thecorresponding output stream, pause the corresponding output stream,adjust an audio volume, start/stop/disconnect/reconnect to thecorresponding output stream, etc. Each test player may also indicate abitrate of the corresponding output stream, a URL from which the streamis being received, a server, an application, a stream name, a streamstatus, and/or whether digital rights management (DRM) is enabled. In aparticular embodiment, each test player corresponds to a software class,package, or application that is dynamically loaded and/or executed by acomputing device (e.g., the computing device 119) in response to userinput 118 requesting testing of the corresponding output stream. Forexample, different test players may simulate and/or emulate playbackoperations of different playback devices 170. When a second outputformat is selected, the computing device 119 may stop execution of, anddeallocate from memory, a test player corresponding to a previouslyselected first output format. Further, the media server 150 may stopsending a first output stream corresponding to the first output formatto the computing device 119 and start sending a second output streamcorresponding to the second output format to the computing device 119.Thus, test players may be loaded by the GUI in just-time-time fashion toreduce a memory and processing footprint of the GUI 115 at the computingdevice 119. Alternately, selecting multiple output formats may causemultiple test players to be loaded and concurrently executed (e.g., totest concurrent output streaming capabilities of the media server 150).In this embodiment, the media server 150 may continue sending the firstoutput stream to the computing device 119 while sending the secondoutput stream to the computing device 119. Output streams may differfrom each other with respect to one or more of streaming protocol,bitrate, resolution, audio encoding, video encoding, etc. Illustrativeexamples of the GUI 115 are presented in FIGS. 2-8.

The system 100 of FIG. 1 may thus enable a user or administrator todynamically test various output streams generated by the media server150 from a single configuration GUI 115. To illustrate, using the GUI115, output streams corresponding to multiple combinations of outputstreaming protocol, video/audio CODEC, bitrate, frame rate, key frameinterval, frame resolution, number of audio channels, etc. may betested. The GUI 115 may thus shorten testing time as compared to havingto configure multiple devices (e.g., mobile phones, tablet computers,set-top boxes, etc.), where each device plays back a singledevice-specific output stream for testing purposes.

It should be noted that the server configuration GUI 115 may presentoptions related to items other than output stream testing. For example,the GUI 115 (which may alternately be referred to as a “web console”)may be used to manage user/administrator accounts for the media server150, including secure sign-in options and read-only accounts. The GUI115 may also be used to configure live and VOD streaming applications.The GUI 115 may further be used to enable or disable certain modules andfunctions of the media server 150, such as the transcoder(s) 155, a DRMmodule, and a network digital video recorder (nDVR) module to recordlive media streams for subsequent playback. The GUI 115 may also includeoptions related to configuring live stream repeaters in accordance withan origin/edge network topology to increase live stream scalability. TheGUI 115 may further include options related to configuring a media cacheto increase VOD stream scalability.

In a particular embodiment, the GUI 115 includes options to configurestreams to start automatically when the media server 150 startsoperation, to manage virtual hosts and internet protocol (IP)addresses/port allocations, to configure username/passwordauthentication for stream publication, to manage security options forclient publishing and playback, or any combination thereof. The GUI 115may also include options to tune performance settings at the mediaserver 150, such as a size of a heap available for dynamic memoryallocation, garbage collection (GC) options, thread pool sizes, andthread allocation settings. The GUI 115 may further be configured todisplay statistics and visualizations, on a collective and/orincoming/outgoing connection basis, to monitor performance of the mediaserver 150 (e.g., processor usage, memory usage, heap usage, disk usage,network throughput, server uptime, etc.). The GUI 115 may also be usedto manage software license keys and to provide one-button restarts ofthe media server 150 or of individual streams/streaming applications.

FIGS. 2-8 illustrate exemplary embodiments of the GUI 115 of FIG. 1.Referring to FIG. 2, a GUI provides the ability to log in to a mediaserver (e.g., the media server 150) for configuration and testingpurposes. In the illustrated example, the media server is located atlocalhost:8087 and the GUI is accessible at localhost:8088 (i.e., theGUI is being displayed at a display device that is part of or coupled tothe media server).

Referring to FIG. 3, a GUI illustrates setting up a VOD streamingapplication (entitled “VOD”). In the illustrated example, HDS, HLS,Smooth, and MPEG-DASH output stream formats are selected. A textual“application description” for the VOD application may also be enteredinto the GUI, as shown. Continuing to FIG. 4, a GUI illustrates playbacksecurity options for VOD streaming, including token-based security andshared secret entry or generation, restriction of video embedding toparticular domains, and client IP address restrictions for streamplayback. A “Test Players” button at the top right of the GUI may beselected to launch a test application that dynamically loads test mediaplayers in response to user input. FIG. 5 illustrates a windowcorresponding to such a test application. In the illustrated embodiment,a tab corresponding to the “DASH” stream output format is selected. Inresponse to selection of the tab, a test player is loaded and executedto view a VOD stream corresponding to a “sample.mp4” file stored at themedia server. In a particular embodiment, the “sample.mp4” file may bedesignated during configuration of the VOD streaming application e.g.,using the “Setup,” “Properties,” or “Modules” tab in the GUI of FIG. 3.As described with reference to FIG. 1, selection of a different tab(e.g., the HDS, RTMP, HLS, Smooth, or Mobile tab) may stop execution ofthe “DASH” test application and initiate execution of another testapplication. Alternately, the “DASH” test application may continue toexecute concurrently with the other application and multiple outputstreams may be received (and optionally displayed) concurrently by thecomputing device displaying the GUI.

Referring to FIG. 6, a GUI illustrates setting up a live streamingapplication (entitled “live”). In the illustrated example, HDS, HLS,Smooth, and MPEG-DASH output stream formats are selected. A textual“application description” for the live application may also be enteredinto the GUI, as shown. Continuing to FIG. 7, a GUI illustrates incomingsecurity options for live streaming, including RTMP/RTSP authentication,client IP address restriction for stream playback, rejection ofduplicate stream names, and version strings. A “Test Players” button atthe top right of the GUI may be selected to launch a test applicationthat dynamically loads test media players in response to user input.FIG. 8 illustrates a window corresponding to such a test application. Inthe illustrated embodiment, a tab corresponding to the “HLS” streamoutput format is selected. In response to selection of the tab, a “HLS”test player is loaded and executed to view a live stream correspondingto the adaptive bitrate (ABR) manifest “manifest.m3u8.” For example, theABR manifest may be the ABR manifest 163 of FIG. 3. As described withreference to FIG. 1, selection of a different tab may stop execution ofthe “HLS” test application and initiate execution of another testapplication. Alternately, the “HLS” test application may continue toexecute concurrently with the other application and multiple outputstreams may be received (and optionally displayed) concurrently by thecomputing device displaying the GUI.

FIG. 9 illustrates a particular embodiment of a method 900 of operationat a media server. In an illustrative embodiment, the method 900 may beperformed by the media server 150 of FIG. 1.

The method 900 includes generating, at a media server, a GUI thatincludes one or more configuration or testing options associated with amedia server, at 902, and sending the GUI to a computing device, at 904.For example, referring to FIG. 1, the media server 150 may generate andsend the GUI 115 to the display device 116.

The method 900 also includes, receiving, at the media server, firstinput responsive to the GUI from the computing device, at 906. The firstinput corresponds to selection at the GUI of a first media playerassociated with a first output stream format. The method 900 furtherincludes, in response to the first input, sending a first output streamin accordance with the first output stream format to the computingdevice, at 908. For example, the “DASH” tab of FIG. 4 or FIG. 9 may beselected. The first format may be smooth streaming and the “DASH” testplayer may be initialized and executed to view the first output stream.

The method 900 includes receiving, at the media server, second inputresponsive to the GUI from the computing device, at 910. The secondinput corresponds to selection at the GUI of a second media player thatis different from the first media player, where the second media playeris associated with a second output stream format that is different fromthe first output stream format. The method 900 also includes, inresponse to the second input, sending a second output stream inaccordance with the second output stream format to the computing device,at 912. For example, the “HLS” tab of FIG. 4 or FIG. 9 may be selected.The second format may be HLS and the “HLS” test player may beinitialized and executed to view the second output stream.

It should be noted that the order of steps or operations described withreference to FIGS. 1-9 is to be considered illustrative, not limiting.In alternate embodiments, the order of steps may be different. Further,one or more steps may be optional and/or replaced by other steps. Inaddition, one or more steps may be consolidated. In accordance withvarious embodiments of the present disclosure, one or more methods,functions, and modules described herein may be implemented by softwareprograms executable by a computer system. Further, implementations caninclude distributed processing, component/object distributed processing,and/or parallel processing.

Particular embodiments can be implemented using a computer systemexecuting a set of instructions that cause the computer system toperform any one or more of the methods or computer-based functionsdisclosed herein. A computer system may include a laptop computer, adesktop computer, a server computer, a mobile phone, a tablet computer,a set-top box, a media player, one or more other computing devices, orany combination thereof. The computer system may be connected, e.g.,using a network, to other computer systems or peripheral devices. Forexample, the computer system or components thereof can include or beincluded within any one or more of the media server 150 of FIG. 1, thedisplay device 116 of FIG. 1, the input device 117 of FIG. 1, thecomputing device 119 of FIG. 1, the desktop/laptop computing device 171of FIG. 1, the TV/set-top box 172 of FIG. 1, the smartphone 173 of FIG.1, the tablet computer 174 of FIG. 1, the media server/stream relayserver 181 of FIG. 1, a server (e.g., edge server) of the CDN 182 FIG.1, or any combination thereof.

In a networked deployment, the computer system may operate in thecapacity of a server or as a client user computer in a server-clientuser network environment, or as a peer computer system in a peer-to-peer(or distributed) network environment. The term “system” can include anycollection of systems or sub-systems that individually or jointlyexecute a set, or multiple sets, of instructions to perform one or morecomputer functions.

In a particular embodiment, the instructions can be embodied in acomputer-readable or a processor-readable device. The terms“computer-readable device” and “processor-readable device” include asingle storage device or multiple storage devices, such as a centralizedor distributed database, and/or associated caches and servers that storeone or more sets of instructions. The terms “computer-readable device”and “processor-readable device” also include any device that is capableof storing a set of instructions for execution by a processor or thatcause a computer system to perform any one or more of the methods oroperations disclosed herein. For example, a computer-readable orprocessor-readable device or storage device may include random accessmemory (RAM), flash memory, read-only memory (ROM), programmableread-only memory (PROM), erasable programmable read-only memory (EPROM),electrically erasable programmable read-only memory (EEPROM), registers,a hard disk, a removable disk, a disc-based memory (e.g., compact discread-only memory (CD-ROM)), a solid-state memory, or any other form ofstorage device. A computer-readable or processor-readable device is nota signal.

As used herein, a “live” stream may differ from a “video on demand”(VOD) stream. A VOD stream originates from, or corresponds to, contentthat is available in its entirety at a stream source when a packet ofthe VOD stream is sent. For example, a VOD stream may correspond to amovie or television show that is stored at a storage device. A livestream corresponds to content that is not available in its entirety whena packet of the live stream is sent. For example, a live stream may beused to transmit audio and/or video content corresponding to an event asthe event is being captured (e.g., in real-time or near-real time).Examples of such events may include, but are not limited to, in-progresssporting events, musical performances, video-conferences, and webcamfeeds. It should be noted that a live stream may be delayed with respectto the event being captured (e.g., in accordance with government orindustry regulations, such as delay regulations enforced by the FederalCommunications Commission (FCC)). It should also be noted that althoughcertain embodiments may be described herein with reference to video ondemand, not all of the described techniques may require video content ordata. Certain embodiments may also be used on demand content that doesnot include video (e.g., audio on demand radio or music streams).

The illustrations of the embodiments described herein are intended toprovide a general understanding of the structure of the variousembodiments. The illustrations are not intended to serve as a completedescription of all of the elements and features of apparatus and systemsthat utilize the structures or methods described herein. Many otherembodiments may be apparent to those of skill in the art upon reviewingthe disclosure. Other embodiments may be utilized and derived from thedisclosure, such that structural and logical substitutions and changesmay be made without departing from the scope of the disclosure.Accordingly, the disclosure and the figures are to be regarded asillustrative rather than restrictive.

Although specific embodiments have been illustrated and describedherein, it should be appreciated that any subsequent arrangementdesigned to achieve the same or similar purpose may be substituted forthe specific embodiments shown. This disclosure is intended to cover anyand all subsequent adaptations or variations of various embodiments.Combinations of the above embodiments, and other embodiments notspecifically described herein, will be apparent to those of skill in theart upon reviewing the description.

The Abstract of the Disclosure is submitted with the understanding thatit will not be used to interpret or limit the scope or meaning of theclaims. In addition, in the foregoing Detailed Description, variousfeatures may be grouped together or described in a single embodiment forthe purpose of streamlining the disclosure. This disclosure is not to beinterpreted as reflecting an intention that the claimed embodimentsrequire more features than are expressly recited in each claim. Rather,as the following claims reflect, inventive subject matter may bedirected to less than all of the features of any of the disclosedembodiments.

The above-disclosed subject matter is to be considered illustrative, andnot restrictive, and the appended claims are intended to cover all suchmodifications, enhancements, and other embodiments, which fall withinthe scope of the present disclosure. Thus, to the maximum extent allowedby law, the scope of the present disclosure is to be determined by thebroadest permissible interpretation of the following claims and theirequivalents, and shall not be restricted or limited by the foregoingdetailed description.

What is claimed is:
 1. A method comprising: receiving, at a mediaserver, first input from a computing device, wherein the first inputcorresponds to selection of a first media player associated with a firstoutput stream format; in response to the first input, sending a firststream preview in accordance with the first output stream format to thecomputing device; receiving, at the media server, second input from thecomputing device, wherein the second input corresponds to selection of asecond media player that is different from the first media player,wherein the second media player is associated with a second outputstream format that is different from the first output stream format; andin response to the second input, sending a second stream preview inaccordance with the second output stream format to the computing device,wherein the first output stream format and the second output streamformat differ from each other with respect to at least one of streamingprotocol, bitrate, frame resolution, frame rate, key frame interval,audio encoding, video encoding, or number of audio channels.
 2. Themethod of claim 1, further comprising generating, at the media server, agraphical user interface (GUI) indicating one or more configuration ortesting options associated with the media server.
 3. The method of claim1, further comprising sending a graphical user interface (GUI) to thecomputing device, wherein the first input and the second input arereceived responsive to the GUI.
 4. The method of claim 1, wherein thecomputing device is remote from the media server.
 5. The method of claim1, wherein at least one of the first input or the second input isreceived via an input device coupled to the computing device, andwherein the first input corresponds to a live stream.
 6. The method ofclaim 1, wherein the second input is received after the first input, andfurther comprising stopping communication of at least a portion of thefirst stream preview to the computing device in response to the secondinput.
 7. The method of claim 1, further comprising continuing to sendthe first stream preview to the computing device while sending thesecond stream preview to the computing device.
 8. The method of claim 1,wherein the first media player corresponds to a first software class orsoftware application, and wherein the second media player corresponds toa second software class or software application.
 9. The method of claim1, wherein the computing device is configured to execute softwarecorresponding to the media server.
 10. An apparatus comprising: aprocessor; and a memory storing instructions that, when executed by theprocessor, cause the processor to perform operations comprising:receiving first input from a computing device, wherein the first inputcorresponds to selection of a first media player associated with a firstoutput stream format; in response to the first input, sending a firststream preview in accordance with the first output stream format to thecomputing device; receiving second input from the computing device,wherein the second input corresponds to selection of a second mediaplayer that is different from the first media player, wherein the secondmedia player is associated with a second output stream format that isdifferent from the first output stream format; and in response to thesecond input, sending a second stream preview in accordance with thesecond output stream format to the computing device, wherein the firstoutput stream format and the second output stream format differ fromeach other with respect to at least one of streaming protocol, bitrate,frame resolution, frame rate, key frame interval, audio encoding, videoencoding, or number of audio channels.
 11. The apparatus of claim 10,wherein the operations further comprises generating a graphical userinterface (GUI) indicating one or more configuration or testing optionsassociated with a media server.
 12. The apparatus of claim 10, whereinthe operations further comprise sending a graphical user interface (GUI)to the computing device, wherein the first input and the second inputare received responsive to the GUI.
 13. The apparatus of claim 10,wherein the second input is received after the first input, and whereinthe operations further comprise stopping communication of at least aportion of the first stream preview to the computing device in responseto the second input.
 14. The apparatus of claim 10, wherein the secondinput is received after the first input, and wherein the operationsfurther comprise continuing to send the first stream preview to thecomputing device while sending the second stream preview to thecomputing device.
 15. The apparatus of claim 10, wherein the first mediaplayer corresponds to a first software class or software application,and wherein the second media player corresponds to a second softwareclass or software application.
 16. A computer-readable storage devicestoring instructions that, when executed by a processor, cause theprocessor to perform operations comprising: sending first input to amedia server, wherein the first input corresponds to selection of afirst media player associated with a first output stream format; inresponse to sending the first input, receiving a first stream preview inaccordance with the first output stream format from the media server;sending second input to the media server, wherein the second inputcorresponds to selection of a second media player that is different fromthe first media player, wherein the second media player is associatedwith a second output stream format that is different from the firstoutput stream format; and in response to sending the second input,receiving a second stream preview in accordance with the second outputstream format from the media server, wherein the first output streamformat and the second output stream format differ from each other withrespect to at least one of streaming protocol, bitrate, frameresolution, frame rate, key frame interval, audio encoding, videoencoding, or number of audio channels.
 17. The computer-readable storagedevice of claim 16, wherein the operations further comprises receiving,from the media server, a graphical user interface (GUI) indicating oneor more configuration or testing options associated with the mediaserver.
 18. The method of claim 1, wherein the first output streamformat associated with a first streaming protocol that is different thana second streaming protocol associated with the second output streamformat.
 19. The method of claim 1, wherein the first stream previewcomprises an adaptive bitrate stream preview.
 20. The method of claim 1,wherein the second input is received concurrently with receiving thefirst input.